One technique for increasing scalability in database systems is to allow multiple nodes to access and modify a single database. A multiple-node system may comprise a single computer with multiple processors, or multiple computers interconnected via a local area network, or a combination thereof. In a multiple-node system, a lock manager may include processes that are distributed over numerous nodes.
One or more database servers may run on the multiple nodes. A database server may include one or more processes. Database servers use and share resources (“shared resources”) while executing transactions. Examples of shared resources include data blocks, tables, and rows. A page is copy of data block loaded into a cache.
Even though resources may be shared between database servers, many resources may not be accessed in certain ways by more than one process at any given time. For example, resources such as data blocks of storage mediums may be concurrently accessed in some ways (e.g. read) by multiple processes, but accessed in other ways (e.g. written to) by only one process at a time. Consequently, mechanisms have been developed which control access to resources.
One such mechanism is referred to as a lock. A lock represents that a particular process has been granted certain rights with respect to a resource. There are many types of locks. For example, a shared type lock may be shared on the same resource by many processes, while an exclusive type lock prevents any other type of lock from being granted on the same resource.
The entity responsible for granting locks on resources is referred to as a lock manager. In a single node database system, a lock manager will typically consist of one or more processes on the node. A lock manager that includes components that reside on two or more nodes is referred to as a distributed lock manager.
FIG. 1 is a block diagram of a multiple-node computer system 100. Each node has stored therein a database server and a portion of a distributed lock management system 132. Specifically, the illustrated system includes three nodes 102, 112, and 122 on which reside database servers 104, 114, and 124, respectively, and lock managers 106, 116 and 126, respectively. Database servers 104, 114 and 124 have access to the same database 120. The database 120 resides on a disk 118 that contains multiple blocks of data. Disk 118 generally represents one or more persistent storage devices which may be on any number of machines, including but not limited to the machines that contain nodes 102, 112 and 122.
According to one approach to distributed lock management, distributed lock management system 132 includes one lock manager for each node that contains a database server. Each lock manager manages access to a subset of the shared resources. A lock manager is referred to as a master with respect to a resource for which the lock manager manages access. If resource R1 is managed by lock manager 106, then lock manager 106 is the master of resource R1. A lock manager is also referred to as a local lock manager with respect to the node on which the lock manager resides. Thus, lock manager 106 is a local lock manager with respect to node 102.
Before a process can access a shared resource, it must obtain the appropriate lock on the resource from distributed lock management system 132. The process issues a request for a lock on a shared resource to distributed lock management system 132. The request specifies a lock name and lock type. The lock name is data that identifies a resource, such as a data block number, a table-id or name, a row-id, or a transaction-id.
Distributed lock management system 132 must determine whether the requested lock is consistent with any lock granted for the resource, if any. If the requested lock is not consistent with the granted lock, then the requester must wait until the process holding the granted lock releases the granted lock.
A process issues a lock request for a resource to its local lock manager. If the local lock manager is not the master of the resource, the local lock manager issues a request for the lock to the master of the resource. The master determines whether the requested lock may be granted, and transmits a response to the local lock manager indicating whether the lock has been granted. The local lock manager updates data structures it maintains to indicate that the lock has been granted to the requesting process. The local lock manager then transmits a lock request response to the requesting process.
Another approach to distributed lock management uses a global lock manager. A global lock manager coordinates requests for locks issued between local lock managers by creating global locks on shared resources. The global locks are granted in tandem with locks granted by local lock managers for shared resources. The global lock manager and local lock managers work together to ensure that a global lock is consistent with the locks granted by the local lock manager, and vice versa.